Sellers charge buyers for the price of goods received by the buyers. Buyers usually will not pay for goods they do not receive, and thus sellers often attempt to confirm that a good was actually delivered to (and/or received by) a buyer before billing the buyer. Among other goals, confirming transactions helps sellers keep accurate billing and accounting records and prevents billing disputes. Thus, sellers have developed a variety of methods to confirm that a buyer has received the relevant goods.
In one common example, a seller's delivery service may require the buyer to sign a receipt indicating delivery and acceptance of the product. Electronic delivery systems, such as those involving communication networks, present unique challenges in confirming the delivery of electronic data. The present invention relates to confirming the delivery of products and services, such as stored-value cards and/or PINs, from a central processor to a user or merchant.
Transactions can be authorized by a central processor, which may deliver the product or service to one or more remote merchant terminals. After a transaction, a party such as the merchant or customer can be billed for the transaction after the transaction is authorized and/or confirmed by the central processor. By way of example, a convenience store merchant may sell a calling card or PIN to a customer. During the sale, the convenience store merchant requests a PIN or calling card authorization code from a central processor over a telephone network. The central station then processes the request and transmits the PIN to the store merchant over the telephone network. The store merchant receives the PIN and delivers it to the customer. Finally, the central station bills the customer or merchant for the price of the PIN.
This example does not include an explicit confirming step. Instead, the central station effectively “confirms” the transaction by virtue of the fact that the central station transmitted the PIN to the merchant terminal. In other words, a merchant is billed because the mere transmission of the PIN by the central processor is sufficient evidence that the PIN must have been received by the merchant terminal (and/or delivered to the customer). It should be appreciated that a PIN can be delivered from a central processor to a merchant terminal to a customer, or directly to a customer. The central processor will bill the customer or the merchant depending on the particular delivery system and the agreements between the various parties.
This simple method can be very efficient when the communication system works properly. However, because errors can sometimes occur, some transactions may never actually be completed. For instance, a PIN may be delivered to a merchant terminal, but the merchant terminal may fail to deliver the PIN to the customer. A merchant employee may request the wrong type of PIN and later cancel the request. Internal and external problems with the merchant terminal, central processor, and/or any communication network between them can cause difficulties in PIN delivery, resulting in a greater need for confirming that a transaction was successfully completed prior to billing. The merchant terminal might not receive a PIN transmitted from the central processor when, for instance, a break in the communication network or a malfunction at the merchant terminal disrupts delivery of the PIN to the merchant or customer. In such cases, the central processor may have no indication that the merchant (or customer) never received a PIN and therefore should not be billed.
A related problem is that a disruption in the communication network may cause a central processor to deem a transaction unsuccessful even though a PIN was successfully delivered to a customer, and the merchant or customer should therefore be billed. Another related issue is identifying the specific PIN transaction to be confirmed when a central processor or merchant terminal handles a series of transactions involving a series of different PINs, or a single transaction with multiple PINs. (In some cases a single transaction with multiple PINs may be functionally similar to multiple transactions with multiple PINs.)
These and other errors may cause a merchant (or central processor or other billing system) to fail to recognize that a transaction was completed even though it received a PIN and delivered it to a customer. Without confirming that a billable event occurred, such as that a PIN or other product was delivered to the proper party, there may be errors in charging purchasers for successful purchases. Largely due to this possibility of errors and the need for accurate accounting records, billing systems typically attempt to confirm that a transaction successfully took place before billing the purchaser.
Various methods have been employed to address the problem of confirming transactions and reconciling billing records. The basic problem is that the central processor must receive confirmation from the merchant terminal that a billable event occurred. In one method, the central processor bills a party only after it receives confirmation from the merchant terminal that a PIN was received at the terminal or that a PIN was delivered to the customer (or other billable event). However, this method has a similar drawback to the simple method: a disruption in a communication, such as the confirmation message, could prevent the central processor from receiving confirmation that the merchant terminal received the PIN (or that the merchant terminal delivered the PIN to the customer). For example, the central processor might successfully deliver a PIN but fail to receive the merchant terminal's message confirming that the billable event occurred. In such a case, the central processor would therefore be unable to determine whether to bill the merchant (or customer, as the case may be).
In an attempt to address these problems, additional verification steps can be added after the billable event occurs. For instance, a more complicated system might require that the merchant release the PIN to a requesting customer (the billable event) only after it receives confirmation that the central processor “knows” the PIN was successfully delivered to the merchant. This method has the following steps: the central processor delivers a PIN; the merchant terminal sends confirmation of receipt; the central processor confirms that it received the merchant's confirmation; the merchant then receives this last confirmation and releases the PIN (the billable event). Naturally, a final confirmation must be sent to the central processor confirming that the billable event occurred.
However, these additional steps do not ultimately solve the underlying problem. A failure to communicate this last step highlights the defect of this method. While the central processor knows that the merchant received the PIN, it does not know whether the billable event occurred. Thus, while the additional steps might provide some useful information, they do not overcome the fundamental problem, and they additionally increase the cost and complexity of the process.
Additional steps in other possible solutions have similar problems. For instance, the merchant terminal may send the central processor a confirmation receipt for a delivered PIN, upon receipt of which the central processor replies with a “confirmation that the confirmation was successfully received,” upon receipt of which the merchant terminal will reply back with a “confirmation that the confirmation of the confirmation was successfully received.” This time, the billable event is defined to occur when the merchant terminal first receives the PIN. When every message is successfully delivered, both the central processor and the merchant terminal will “know” that a PIN was delivered and a party should be billed. However, if the central processor does not receive the initial confirmation receipt, the central processor still cannot determine whether the merchant terminal received the initial PIN transmission (the billable event).
A related system might condition PIN delivery to the customer (the billable event) upon the successful completion of each of the above steps. While this system will tend to avoid billing customers who never received a PIN, it will fail to bill for successful PIN deliveries (billable events) when errors prevent the central processor from receiving the final confirmation message, namely, a “confirmation that the confirmation of the confirmation was successfully received.”
The fundamental problem in any system of this type is sometimes called an “infinite acknowledgement” or “infinite loop” problem because no matter how many times confirmation messages are communicated back and forth between two parties, the first party can never be certain that the second party received the last communication. It should be noted that in these examples, the merchant has exclusive knowledge that a billable event occurred, and the central processor has the PINs and exclusive control over billing. The problem is that the communication from the merchant to the central processor confirming the billable event might fail.
In one of the more efficient billing reconciliation methods used in the art, each current transaction request by a terminal verifies the prior transaction on record at the central processor. The merchant terminal transmits with each new transaction request a prior transaction identifier that identifies the last transaction completed by the terminal, e.g., the last transaction that is deemed by the merchant terminal to be successfully delivered to a customer. When the central processor receives the prior transaction identifier from the merchant, it can then confirm that such transaction was completed, and the appropriate party can be billed. (The central processor also processes the current transaction request, although the current transaction can only be verified during the next transaction request.) Ideally, each prior transaction identifier transmitted by a requesting terminal will match the central processor's last recorded transaction with that requesting terminal. However, because of communication errors, the prior transaction identifier received by the processor will occasionally fail to match the processor's records, such as when the merchant terminal fails to receive a PIN transmitted from the central processor due to an error.
According to this prior art method, at the end of the billing cycle, e.g., at the end of the month, all the transactions that were confirmed by the central processor are billed to the appropriate parties. All the transactions that were not confirmed are then acknowledged as unconfirmed, and action can be taken to investigate whether to bill a party for such transactions. Some questionable transactions may become effectively confirmed when, for example, a customer activates a questionable PIN, thereby indicating that the customer must have received the questionable PIN. Other questionable transactions may require further communication with the merchant, customer, or third parties, or other investigation.
This prior art method could be considered “passive” since data is merely collected during a billing cycle, and billing issues are not considered until the end of the billing cycle. The primary disadvantage of this method is the time delay until the end of the billing cycle. During the passage of time, the information necessary to determine whether a given transaction occurred may disappear or fade, leading to increasingly inaccurate billing records and increasingly costly reconciliation efforts. Further, delays in billing cause a loss in the time value of money since delayed bills may result in delayed payments.
What is needed is a billing reconciliation system and method that efficiently confirms transactions with a minimum of cost and complexity. What is further needed is a billing reconciliation system and method that determines the confirmation status of transactions in a prompt manner.